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(57) ABSTRACT 

A method of performing a network management transaction 
between a nefwork device, having a network management 
agent installed thereon, and a remote device, having a 
web-browser installed thereon. is _described. The method 
involves firstly performing a-netw^g^managementiunction 
relating to the network devic e. Data concerning the network 
management function is then propagated from the agent to 
the remote device in a format capable of display by the 
browser. More specifically, a document is propagated from 
the agent to the remote device for display by the browser, the 
document incorporating the data concerning the network 
management function. The document may be an HTML 
document. Alternatively, the data may be propagated in a 
format for display by the browser under the direction of an 
application program resident of the remote device.. 
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which translates the message into a format required by the 
HTTP protocol. After performing the translation, the proxy 
agent 24 then propagates the message to the client 22. 

[0009] FIG. IB shows the network management station 
12 and the network device 14 which communicate network 
management information according to the SNMP protocol, 
as described above. However, the proxy agent 24 is now 
shown to reside on the network device 14, instead of the 
network management station 12. In the shown arrangement, 
the client 22 installed on the remote device 20 communi- 
cates with the network management agent 18 via the proxy 
agent 24 as described above. In this case, the proxy agent 24 
translates a message received from the client 22 from a 
format specified by the HTTP protocol to a format specified 
by the SNMP format. Similarly, a message from the network 
management agent 18 to the client 22 is translated by the 
proxy agent 24 from a format specified by the SNMP 
protocol to a format specified by the HTFP protocol. 

[0010] While the arrangements shown in FIGS. 1A and 
IB allow a degree of network management to be performed 
from a client 22 resident on a remote device, there are a 
number of limitations inherent in these arrangements. Spe- 
cifically, the HTTP protocol is primarily intended to facili- 
tate the retrieval of static documents by a client from a 
server. The SNMP protocol is intended to facilitate network 
management in a simple and effective manner. Furthermore, 
the existence of a proxy agent for the translation of messages 
between the two protocols is inefficient and undesirable. 

SUMMARY OF THE INVENTION 

[0011] The present invention contemplates a network 
management protocol wherein a me thod token, associate d 
wi th a netwo rk^management_functiQn,_is_incorporated,or_ 
embedded directl y into a Uniform Resource Locator (URL) 
or^Uniform Resource Identifier (URI) propagated from a 
browser. Data generated by the performance of the network 
management function is then communicated by a network 
management agent to a browser in a format that can be 
displayed by the browser. 

[0012] According to the invention there is provided a 
method of performing a network management transaction 
between a network device having a network management 
agent installed thereon and a remote device having a 
browser installed thereon. The method involves firstly per- 
forming a network management function relating to the 
network device. Data concerning the network management 
function is then propagated from the agent to the remote 
device in a format capable of display by the browser. More 
specifically, a HTML document is composed by the agent 
and then propagated from the agent to the remote device for 
display by the browser, the document incorporating the data 
concerning the network management function. Alterna- 
tively, the data may be propagated in a format for display by 
the browser under the direction of an application program 
resident of the remote device. 

[0013] The network management function relating to the 
network device is performed in response to a network 
management request issued from the browser. The network 
management request may be included in a data packet 
received at the agent, the data packet including a plurality of 
network management requests. The network management 
function addresses a network management object, and per- 



forming the network management function requires that an 
object identifier included within the network management 
request be associated with the network management object. 

[0014] Prior to a network management request being 
issued from the browser, a list of network management 
functions supported by the agent is sent from the agent to the 
remote device. The agent may also transmit a menu HTML 
document to the remote device for display by the browser, 
the menu document providing an option to issue the request 
from the browser to the agent. The menu HTML document 
includes static information concerning the network device, 
and includes a number of URIs (or URLs) including embed- 
ded method tokens for initiating network management func- 
tions. 

[0015] A network management function may involve the 
retrieval of network management information, the allocation 
of a value of a network management object, or the setting of 
a trap on a network management object. 

[0016] A connection is established between the agent and 
the browser, and the connection is maintained for multiple 
network management transactions between the agent and the 
remote device. 

[0017] The invention extends to a computer-readable 
medium having a plurality of instructions thereon which, 
when executed by a processor within the network device, 
cause the processor to perform the steps detailed above. 

[0018] The invention also extends to a network device 
having a processor and a memory coupled to the processor, 
the memory storing a set of instructions which, when 
executed by the processor, cause the processor to perform 
the steps detailed above. 

[0019] Other features of the present invention will be 
apparent from the accompanying drawings and from the 
detailed description which follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0020] The present invention is illustrated by way of 
example and not limitation in the figures of the accompa- 
nying drawings, in which like references indicate similar 
elements and in which: 

[0021] FIGS. 1A and IB are schematic representations of 
arrangements for managing a network from a remote device 
having a web-browser installed thereon. 

[0022] FIG. 2 is a schematic representation of a network 
device having a network management agent according to the 
present invention installed thereon, and connected to remote 
devices via an internet or an intranet. 

[0023] FIG. 3 is a schematic representation of a network 
device on which the network management agent according 
to the present invention is installed, and having a storage 
device including a computer-readable medium on which the 
agent is stored. 

[0024] FIG. 4 is a diagrammatic representation of a Uni- 
form Resource Locator (URL) Dictionary according to the 
present invention. 

[0025] FIG. 5 provides a diagrammatic representation of 
data files maintained by the network management agent 
according to the present invention. 
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METHOD OF PERFORMING A NETWORK 
MANAGEMENT TRANSACTION USING A 
WEB-CAPABLE AGENT 

FIELD OF THE INVENTION 

[0001] The present invention pertains to the field of net- 
work management. More particularly, the present invention 
relates to a protocol for performing network management 
using a web -capable network management agent. 

BACKGROUND OF THE INVENTION 

[0002] The proliferation of both local area networks 
(LANs) and wide area network (WANs) has resulted in 
increasing demands being made on network management 
tools and on network management personnel. In order to 
increase the ease and speed with which network manage- 
ment personnel are able to perform management tasks and 
respond to network problems, it is desirable to provide such 
personnel with convenient and ready access to network 
management tools. 

[0003] The Internet, and more specifically the World Wide 
Web (hereinafter referred to as "the web") component 
thereof, have become increasingly accepted as a medium of 
data communication in recent years. Programs which allow 
documents and objects to be retrieved from the web, and to 
be viewed are genetically termed "web browsers". Hyper- 
text Markup Language (HTML) is the language used for the 
construction of documents that are viewable by web brows- 
ers, and a specification of this language is provided in the 
Request For Comments (RFC) document by Berners-Lee, 
T, D. Connolly, "Hypertext Markup Lanugue-2.0", RFC 
1866 MIT Laboratory of Computer Science, November 
1995. A large number of browsers are commercially avail- 
able, including the Netscape Navigator® browser developed 
by Netscape Communications of Mountain View, Calif., and 
the Microsoft Internet Explorer® browser developed by 
Microsoft Corporation of Redmond, Wash. 

[0004] While browsers operate to display HTML docu- 
ments, they are also responsible for negotiating a Hypertext 
Transport Protocol (HTTP) with a web server prior to the 
retrieval of an HTML document or other object, the sub- 
mission of information from the browser to a web server, 
and responding to requests to "link" to (or retrieve) other 
HTML documents identified in an HTML document cur- 
rently displayed by the browser. The capabilities of web 
browsers and servers are further continually being enhanced 
by the development of so-called "plug-ins", which are 
software modules which can be added to web browser and 
server software to provide enhanced functionality. 

[0005] In view of the popularity and proliferation of the 
web browsers there has been some development towards 
allowing network managers to perform network manage- 
ment functions utilizing a web browser over the internet or 
an intranet Referring to FIGS. 1A and IB, two arrange- 
ments for facilitating management of a network 10, utilizing 
a web browser, are illustrated. The network segment 10 
comprises a network management station 12 and a network 
device 14, which may be a host, gateway, terminal server, 
hub, repeater, bridge or frame switch. A network manage- 
ment application 16 resides on the network management 
station 12, while a network management agent 18 resides on 
the network device 14. The application 16 and the agent 18 



communicate management information using the Simple 
Network Management Protocol (SNMP), as defined in the 
RFC by Case, J. M. Fendor, M. Schoffstal, and J. Davin, 
"The Simple Network Management Protocol", RFC 1157 
University of Tennessee at Knoxville; Performance Systems 
International, Performance Systems International, and the 
MIT Laboratory of Computer Science, May 1990. More 
specifically, the agent 18 will provide the application 16 with 
status information regarding network activity relating to the 
network device 14, either when polled by the application 16, 
or as a trap. The application 16 assimilates network status 
information from a number of network management agents 
to provide a network manager with an overall view of 
network activity and status. A network manager can perform 
network management functions by receiving messages from 
and sending messages to the agent 18. 

[0006] All network management functions with an SNMP 
environment are performed by altering and inspecting vari- 
ables or "managed objects". These managed objects are 
termed Management Information Base (MIB) objects, and 
each network management agent 18 supports a predeter- 
mined set of MIB objects (termed an SNMP MIB view of 
that agent). The sets of MIB objects supported by various 
network management agents may vary from network device 
to network device. A number of MIB objects are defined in 
the RFC by McCloghrie, K., and M. Rose, "Management 
Information Base for Network Management of TCP/IP- 
based Internets", RFC 1156, Hughes LAN Systems and 
Performance Systems International, May 1990. Examples of 
such managed objects includes the "sysUpTime" object 
(which provides a value indicating the time since the net- 
work management portion of a system was last re -initial- 
ized) and the "ifAdminStatus" object (which indicates 
whether an interface is up, down or in a testing state). 

[0007] In order to maintain the simplicity of the SNMP, 
the exchange of messages using the SNMP utilizes an 
unreliable datagram service, such as the User Datagram 
Protocol (UDP) as specified in the RFC by Poster, J., "User 
Datagram Protocol", RFC 7683 USC/Information Sciences 
Institute, November 1980. The UDP protocol allows the 
transmission of message packets in a serial fashion, and 
accordingly has a limited bandwidth. 

[0008] Also shown is FIG. 1A is a remote device 20, such 
a desktop computer, on which is resident a client 22 in the 
form of a web browser. The client 22 communicates with a 
proxy agent 24, which is resident on the network manage- 
ment station 12 using the Hypertext Transfer Protocol 
(HTTP), as defined in the RFC by Fielding, R M H. Frystyk, 
T. Berners-Lee, J. Gettys, J. C. Mogul, "Hypertext Transfer 
Protocol-HTTP/LL', RFCxxxx, UC Irvine, MIT Laboratory 
of Computer Science, MIT Laboratory of Computer Sci- 
ence, DEC, DEC, April 1996. Accordingly, al! data packages 
passed between the client 22 and the proxy engine 24 
conform to the HTTP protocol. The proxy agent 24 receives 
and translates data packages from the client 22 into a format 
understood by the network management application 16, 
before propagating the translated message to the application 
16. Accordingly, the proxy agent 24 is an intermediate 
program which acts as both a server and a client for the 
purposes of translating and forwarding requests to the appli- 
cation 16 on behalf of the client 22. Similarly, messages 
intended for transmission from the application 16 to the 
client 22 must firstly be propagated to the proxy agent 24, 
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[0026] FIG. 6 is a schematic representation of a number of 
the modules, objects and files which comprise the network 
management agent according to the present invention. 

[0027] FIG. 7 is a diagrammatic representation of a num- 
ber of software modules that are invocable within the 
network management agent of the present invention. 

[0028] FIG. 8 is a flow chart illustrating a method accord- 
ing to the present invention by which the network manage- 
ment agent processes a received network management 
request. 

[0029] FIG. 9 is a state diagram illustrating the states in 
which a request manager software module, comprising part 
of the network management agent according to the present 
invention, can reside. 

[0030] FIG. 10A shows the software functional layers 
within a network device shown in FIG, IB. 

[0031] FIG. 10B shows the software functional layers 
within a network device according to the present invention. 

[0032] FIG. 11 is a flow chart illustrating a generic 
method of performing a network management transaction 
according to the present invention. 

[0033] FIGS. 12-14 are flow charts illustrating specific 
examples of the generic method shown in FIG. 11. 

[0034] FIGS. 15A-15C are schematic illustrations of the 
exchange of request and response messages between a 
browser and a network management agent according to a 
protocol proposed by the present invention. 

[0035] FIG. 16 is a diagrammatic representation of a 
request message structure according to the present inven- 
tion. 

[0036] FIG. 17 is a diagrammatic representation of a 
response message structure according to the present inven- 
tion. 

DETAILED DESCRIPTION 

[0037] A method of performing a network management 
transaction using a web-capable agent is described. In the 
following description, for purposes of explanation, numer- 
ous specific details are set forth in order to provide a 
thorough understanding of the present invention. It will be 
evident, however, to one skilled in the art that the present 
invention may be practiced without these specific details. 

[0038] 1. Terminology 

[0039] The terms specified below are used throughout the 
specification, and are intended to have the import, and 
encompass the concepts, as stated below: 

[0040] 1.) Uniform Resource Identifier (URI): URPs are 
data strings intended to identify, via name, location or any 
other characteristic, a network resource. The term URI is 
intended to encompass a number of terms common in the art, 
namely a Uniform Resource Locator (URL), a Uniform 
Resource Name (URN), a world wide web address, and an 
Universal Document Identifier (UDI). 

[0041] 2.) Resource: Any network data object, variable or 
service. 

[0042] 3.) Client: A program which, inter alia, establishes 
a connection with a server for the purposes of sending or 
receiving data. 



[0043] 2. Overview of the Invention 

[0044] The present invention seeks to address the limita- 
tions of the arrangements presented in FIGS. 1A and IB by 
providing a web-capable program (which may be either a 
network management application or a network management 
agent) which will support a number of network management 
nmcfions, and will have the capability of propagating infor- 
mation regarding such network management functions in a 
format that is capable of display on a web browser. Accord- 
ingly, a web-capable network management agent proposed 
by the present invention will present network management 
information in the format of a HTML document, or in a 
format which may be used by an application which interacts 
with the browser to produce an HTML document represent- 
ing the relevant network management information. In one 
embodiment, such an application may be a J AVA^^ppjeT^ 

[0045] The present invention also proposes a protocol, 
conveniently termed the Hypertext Network Management 
Protocol (HNMP) according to which a web-capable net- 
work management agentan d a client can exchange data. I n 
one embodiment, this is achieved by introducing an embed- 
ded method token directly into a URL string of a message 
transmitted from a client to the network management agent. 
Appropriate action is then applied to an identified URL 
object based on the embedded method token. 

[0046] A description of the hardware in which the present 
invention may be employed, as well as the structure of the 
software which comprises the present invention will firstly 
be described below. Thereafter, a description of the meth- 
odology employed by the present invention will be pro- 
vided. 

[0047] 3. System Description 
[0048] 3.1 Network 

[0049] Referring to FIG. 2, in one embodiment of the 
present invention, an embedded, web-capable network man- 
agement agent 30 resides on a network device 32, to which 
a number of end devices 34 are coupled. The network device 
32 may be a router, bridge, hub or any other network device 
on which network management agents commonly reside. 
The end devices 34 may be computers, servers, or peripheral 
devices. It wilt be appreciated that the network device 32 
may furthermore be coupled to any number of Jurther_ 
network devices. 

[0050] The network device 32 is shown to be coupled to 
an intranet 36 and an internet 38. Also coupled to the internet 
36 is a remote device 38, such as a computer, on which 
resides a client 40, in the form of a web browser. Similarly, 
remote devices 42 and 44 each have a client 40 installed 
thereon and are coupled to the internet 38. The clients 40 
propagate request messages to the network management 
agent 30 which, in response to the request messages, propa- 
gates response messages to the clients 40. In one embodi- 
ment, these response messages incorporate HTML docu- 
ments, and accordingly the network device 32 may be 
viewed by the clients 40 as an HTML server. The network 
management agent 30 supports a set of managed objects, 
which in one embodiment are Management Inform ation 
Base JMIB) objects . Ths set of Ml R "hj ft <1fi ft 1 lppP rtpfi K y the 
ag ent 30 are specific to the network device 3g . and are 
termed the MI B view of the agent 30. The managed objects 
(or variables) provide information regarding the network 
device, such as, for example, the number of good or bad data 
frames received at and transmitted from the network device 
32. 
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[0051] Requests received from client 40 address the man- 
aged objects supported by the agent 30 and, as will be 
described in further detail below, may request network 
management information regarding the network device 32 
fr om the agent 30. This information i s the n p ropagated jojhe 
cl ient 40 in a forma t .wjuch.can^be^displayedon-thejequest- 
i ng client ^ 0. 

[0052] 3.2 The Network Device 

[0053] FIG. 3 shows one possible embodiment of a net- 
work device 32 in the form of a computer. The network 
device 32 includes a processor 50 for executing the various 
sequences of instructions which comprise the web-capable 
network management agent 30. The network device 32 
further includes a main memory 52, in which the sequences 
of instructions which comprise the agent 30 may at least 
partially reside, as shown in FIG. 3, when the sequences of 
instructions are being executed by the processor SO^JQis. 
deyice 32 further incorporates a mass storage device 54 
which irTone embodiment comprises a drive which opera tes 
t o read data from, and wri te.data.tQ._a_e o_mputer readab le 
medium 56 on which the sequences of instructions compr is- 
i ng the agent 30 may be stored. 

[0054] 3.3 The Web-Capable Network Management Agent 

[0055] The web-capable network management 30 com- 
prises a number of manager modules, execution modules 
and data structures, the data structures being modified and 
maintained by the manager and execution modules. The 
agent 30 furthermore comprises an interface, namely a URL 
dictionary for interfacing between the various modules and 
the data structures. 

[0056] 3.3.1 The URL Dictionary and Data Structures 

[0057] Referring now to FIG. 4, the network management 
agent 30 maintains a Uniform Resource Locator Dictionary 
(URLD) 60, which contains an entry 62 for each managed 
object supported by the agent 30. Each entry 62 comprises 
a number of fields including an OBJECT NAME deld 64, 
and OBJECT IDENTIFIER field 66, a DATATYPE field 68 
and an ENUMERATION TABLE field 70. The OBJECT 
NAME field 64 contains a textual name for the managed 
object, which corresponds to a numeric object identifier 
contained in the OBJECT IDENTIFIER field 66. The DATA 
TYPE field 68 indicates whether an instance of the object 
will be an octet string, integer, or enumeration. In the case 
where the data type is indicated as being an enumeration, the 
ENUMERATION TABLE field 70 contains an integer cor- 
responding to a status. For example, referring to entry 62.2 
in the URLD 60, the data type is indicated as being an 
ENUMERATION, and the ENUMERATION TABLE field 
70 indicates a value "1**, corresponding to an "up" status. 
Similarly, a value of "2" in field 70 would indicate a "down" 
status, whereas a value "3" would indicate a "testing" status. 
The last entry in the dictionary, namely entry 62.N contains 
zeroes in all fields. 

[0058] The URLD 60 provides the main interface between 
a request manager module, and the managed objects and file 
system of the agent 30. In one embodiment, the managed 
objects all comprise M1B objects, which may in turn be 
classified as SNMP objects, file objects, counter objects and 
miscellaneous objects. 

[0059] FIG. 5 shows the three primary data file types that 
are maintained by the web-capable network management 
agent 30. These file types comprise transaction control 



blocks (TCB) 72, unit data blocks (UDB) 74, and URL 
blocks (URLB) 76. Referring firstly to the transaction con- 
trol blocks 72, a TCB 72 is created for each incoming 
request received at the network management agent 30 from 
a client 40. Each TCB 72 contains the following fields or 
attributes: 

[0060] 1. a unit data block identifier (UDB ID): The 
contents of this field identify a corresponding entry in the 
unit data block 74. 

[0061] 2. a received input data pointer: The memory 
references to the incoming data from the client 40. 

[0062] 3. a socket identifier: The contents of this field 
indicate the socket in which the incoming request was 
received. 

[0063] 4. a URLD Identifier: The identification of one of 
the many URLs in the URL dictionary. In essence, it is the 
address of a specific object in the URL pool. 

[0064] 5. a Header Record Pointer: The attributes related 
to the client request which are specific to the HTTP protocol. 
It allows both the Client and Server dealing in HTTP to 
exchange objects (URLs). 

[0065] Response data to be provided by the agent 30 to a 
client may be too large to be written to a contiguous output 
buffer. Accordingly, response data may be divided into a 
number of blocks, each of which comprises a unit data block 
74. Each unit data block 74 contains the following fields or 
attributes: 

[0066] 1. a pointer to a following, consecutive UDB 74. 

[0067] 2. the relevant response data. 

[0068] Each URL instance has an allocated URL Block 76, 
which contains attributes relating it to the relevant URL. 
Each URL Block 76 will include the following fields or 
attributes: 

[0069] 1. the URI: This is the string which represents a 
managed object. The URI is the name of the URL object and 
items 2-5 below are the attributes. 

[0070] 2. an Action Method included within the URL 
instance: In one embodiment, the following methods could 
be indicated as being Action Methods: 

[0071] (a)ls:list files or directories 

[0072] (b)cat<filename>:display a file. 

[0073] (c)cr<filename>:create a file in the "/usr" 
directory. 

[0074] (d)rm<filename>: remove a file from the 
"/ust" directory. 

[0075] (e)ld<filename>:load a file from browser to 
the ^sr" directory in the server. 

[0076] (Qselect: select the columns in a table. 

[0077] 3. Arguments: This is an array of argument records, 
and incorporates an argument name and an argument value. 

[0078] 4. URL Type: This field indicates the file extension 
type such as, for example, ".moca", ".html", ".gif", or ".txt". 

[0079] 5. Mode: This indicates the output format of the 
URL. 
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[0080] 3.3.2 Manager Modules (The HTML Server) 

[0081] FIG. 6 illustrates a number of the primary modules 
and objects of the web-capable network management agent 
30, and also illustrates the interaction between these mod- 
ules and objects. Three manager modules are shown to 
comprise a so-called "HTML server"80, these manager 
modules comprising a task manager 82, a request manager 
84 and a response manager 86. The manager modules which 
comprise the HTML server 80 manage network manage- 
ment functions performed in response to requests received 
from the client 40. 

[0082] The task manager 82 is a daemon which is acti- 
vated on system initialization and creates a socket on a 
dedicated HTML port (for example, port 80) and then listens 
on that port for incoming requests propagated to the agent 30 
from a client 40. Upon receipt of an incoming request, the 
task manager 82 creates a socket, and spawns a request 
manager 84, whirh is frxMcAteA tp ma n aging th e-recei ved 
request^This process repeats itself until a predetermined 
number (for example four) of socket and request manager 
pairings have been created. Once the predetermined number 
of sockets and request manager pairings have been created, 
the task manager will distribute further incoming requests to 
queues associated with each pairing on a rotating basis. 

[0083] As stated above, a dedicated request manager 84 is 
assigned to manage each incoming request received at the 
agent 30 from a client 40. The request manager 84 is central 
to the HTML server 80, and interacts with the response 
manager 86, the URL dictionary 60 and a number of 
execution modules to process the request and initialize a set 
of data files, as shown in FIG. 5, for the request. A detailed 
explanation of the functioning of the request manager 84 
will be provided below. 

[0084] The response manager 86 has the task of formatting 
and buffering output data, which is to be propagated from 
the agent 30 to the client 40 as a response to a request. 

[0085] 3.3.3 Execution Modules 

[0086] FIG. 7 shows a grouping of execution modules 
which are called, or initiated, by the request manager 84 to 
perform specific functions in processing of a request. 

[0087] 1 . a Tokenizer module 90: A tokenizer module is a 
module which has the embedded knowledge to separate the 
incoming stream of data into manageable tokens. Based on 
this knowledge the tokenizer module 90 determines whether 
or not the incoming data conforms to the negotiated proto- 
col. It is called by the request manager 84 which feeds it the 
data stream. The tokenizer module 90 breaks down the data 
stream into tokens and then activates appropriate parsers for 
each of the tokens. 

[0088] 2. a Command Line (CU) Parser 92: The CLI 
parser 92 is responsible for parsing a request-line of a 
request message received at the agent 30 and for initializing 
a URL block 76 for the request with information, described 
above, pertaining to that request. 

[0089] 3. a Head Parser 94: This module parses a Request - 
Header of a request message received at the agent 30. The 
head parser module 94 is responsible for initializing a 
transaction control block 72 for a received request message. 
The header of the request message is parsed to extract data 
contained in the following fields: 



[0090] 1. <HTTP- Versions the version of HTTP 
supported by the client (browser). 

[0091] 2. <if-Modified-Since>: the expiration date of 
the URL 

[0092] 3. <Allow>: methods applied to the URI. 

[0093] 4. <Content-Length>: the length of the entity 
body of the request message. 

[0094] 5. <Content-Type>: the URI type (text, html, 
gif> 

[0095] 4. Entity Body Parser 96: This module is respon- 
sible for parsing the entity body of a request message 
received from the client 40, or a response message to be 
propagated to the client 40, to locate a Server Side Include 
(SSI). A Server Side Include is a tag within a HTML 
document which indicates to a server, from which an HTML 
document is being propagated, that information accessible 
by the server is to be incorporated into the HTML document. 
SSI tags are understood only on the server side, and are 
especially useful to include the result of a certain action 
taken on the server side (i.e. dynamic data) within a static 
HTML document. Accordingly, by using SSI tags, it is 
possible to create an HTML document which interlaces 
static and dynamic data. The following code sets out an 
illustrative example of an HTML document incorporating 
SSI tags. In the present invention, a <MOCA> tag (and a 
corresponding </MOCA?- tag) identify the SSI portion of an 
HTML document. 



<IDOCTYPE HTML PUBLIC "-//tETF/ZUTD HTML//EN"> 

<HTML> 

<HEAD> 

<TTTLE>Presto Home Page</TtTLE> 

</HEAD> 

<BODY> 

Welcome to the Presto Home Page. Fasten your surfbelt and hop on in 

for an adventurous tour of my Home and neighbor. 

<UL> 

<LIxA HREF=*7system/presto. html "> About Me</A> 
<LI><A HREF-"/system Aopology.htm l">My neighbor</A> 
<LI><A HREFe"/systcm/documcnts.htmr'>Uscrs Guidc</A> 
</UL> 

My current Port Status Table: 
<BR> 

<TABLE BORDER> 

<CAPTION>Presto Port Status Table </CAPTION> 

<MOCA codc=sclcct> 

< PA RAM -"Table" value="s5EnPortTabIe"> 

</MOCA> 

</TABLE> 

<P> 

</BODY> 
</HTML> 



[0096] For example, the entity body parser module 96 
recognizes the following SSI commands as being valid when 
included between the <MOCA> and </MOCA> tags as 
identified above: 

[0097] 1. Is: list files or directories. 

[0098] 2. cat: display files. 

[0099] 3. cr: create a file in a user directory. 

[0100] 4. rm: remove a file from a user directory. 
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[0101] 5. Id: load a file from a browser to a user 
directory in the server. 

[0102] 6. select: select the columns in a table sorted 
by column in ascending or descending order. 

[0103] 5. a Start URL module 98: this module is called by 
the request manager 84, and once activated, proceeds to 
retrieve a URL name and its type from the URL Block 36. 
The module then recognizes the URL type, and accesses the 
resource identified by the URL from an appropriate location. 
For example, if the URL identifies a file, the file is accessed 
via a file read system. If the URL is identified as being a 
MOCA command, then a MOCA library is accessed. Alter- 
natively, if the URL identifies a managed object, this object 
is then accessed via the URL Dictionary 60. 

[0104] There are furthermore a number of callback func- 
tions within the MOCA library, namely: 

[0105] 6. Moca_ls module 100: this callback function 
accesses the file system, and retrieves file names which are 
then formatted into HTML format in the appropriate Unit 
Data Block 74 for propagation to the client 40. 

[0106] 7. Moca_ld module 102: this callback function is 
used to load and transfer a remote file to the agent 30. The 
location of the remote file is determined by an agent config 
file, and the file name in the URL. 

[0107] 8. Moca_get module 104: this module is used to get 
the value of a certain object (URL) within the URL dictio- 
nary. 

[0108] 9. Moca_set 105: this module is used to set the 
value of a read and write object within the URL dictionary. 

[0109] 10. Moca_select 106: this call back function is used 
to provide formatted output table data. 

[0110] 3.3.4 Methodology— the HTML server 

[0111] The method by which a request received at the 
HTML server 80, comprising the task manager 82, the 
request manager 84 and the response manager 86, is pro- 
cessed will now be described with reference to FIGS. 6, 8 
and 9. FIG. 8 is a flow chart indicating the various steps 
performed by the HTML server 80, and FIG. 9 is a state 
diagram, indicating the various states in which the request 
manager 84 resides during performance of the steps shown 
in the flow chart of FIG. 8. 

[0112] Referring firstly to FIG. 8, at step 112 the task 
manager 82 creates a socket on a dedicated port, for example 
port 80, and then listens at that port for an incoming request 
from the client 40. On the receipt of a request, and the 
establishment of a TCP/IP connection for that request, the 
task manager creates a new socket and a dedicated request 
manager to oversee the processing of the request. 

[0113] At step 114, the incoming request is received at the 
request manager 84 for processing. The request manager is 
at this time in an idle state 150, and calls the Tokenizer 
Module 90, Command Line Parser 92, the Head Parser 94 
and the Entity Body Parser 96 to parse the request at step 116 
of the method 110. At step 118, the data extracted from the 
request is stored in a transaction control block (TCB) 72 and 
at least one URL block (URLB) 76 associated with the 
request. More specifically, the Command Line Parser 92 
parses a request -line of the request, and initializes (or 



creates) a URL block 76 with values for the attributes of 
such a block, as discussed above. The Head Parser 94 parses 
the headers of the request and initializes a Transaction 
Control Block (TCB) 72 for the request. The Entity Body 
Parser 96 then parses the entity data body of the message to 
search for any Server Side Includes (SSIs), and creates and 
initializes a further URL Block 76 for each SSI encountered. 

[0114] At step 120, the request manager 84 enters an 
active state 152, as shown in FIG. 9, and interfaces with the 
URL Dictionary 60 via an appropriate Application Program 
Interface (API) to activate the requested method (now 
indicated in the URL block 76) on a URL object identified 
in the request. More specifically, the request manager 84 
interfaces with the URL Dictionary 60 by calling the Start 
URL module 98. The URL Dictionary 60 then uses the URL 
attribute value maintained in the appropriate URL Block 76 
to access the managed objects 88 (as shown in FIG. 6), or 
the file system 89. At step 122, assuming the access opera- 
tion is successful, the URL Dictionary 60 returns output data 
to the request manager 84, in the form of a series of Unit 
Data Blocks 74. 

[0115] At step 124, the output data is again parsed by the 
Entity Body Parser module 96 to locate any Server Side 
Includes within the output. If the Entity Body Parser module 
96 locates a Server Side Include in the output at decision 
block 126, the method proceeds to step 128 wherein the 
request manager 84 again interfaces with the URL Dictio- 
nary 60 to activate the method of the Server Side Include on 
a URL object. This iteration proceeds until it is determined 
at decision block 130 that all output data has been parsed. 
The method 110 then proceeds to step 132, where the request 
manager 84 enters the sending state 154, as shown in FIG. 
9. The request manager 84 then communicates with the 
response manager 86 by instructing the response manager 86 
to flush "ready to send" data to the client 40. On receiving 
a successful handshake from the response manager 80, the 
request manager 84 returns to the active state 152. On the 
other hand, should a transmission or "time out" error occur 
at this stage, the request manager enters a release state 156. 
Errors may result from the following: 

[0116] 1. the client might close the connection prema- 
turely; or 

[0117] 2. there may not be any further buffer capacity 
available at the transport level to send out any more data. 

[0118] Assuming a successful handshake with the 
response manager 86, the request manager 84 will transition 
from the active state 152 to the release state 156, and will 
release all resources associated with the request and return 
to the idle state 150. 

[0119] It may also occur that, at step 122, the output data 
received from the URL Dictionary 60 may exceed the 
capacity of an output buffer, in which case the request 
manager 84 enters the sending state 154 and communicates 
with the response manager 86 to flush the contents of the 
output buffer to a client 40. Once the output buffer has been 
flushed, the request manager 84 then returns to the active 
state 152. 

[0120] The response manager 86 transitions between an 
idle slate (not shown) and an active state (not shown). More 
specifically, in the idle state, the response manager 86 waits 
for an incoming request directing that a UDB 74 chain be 
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sent over a socket specified in an appropriate Transaction 
Control Block 72. The response manager 86 enters the active 
state once it received a UDB 74 from the request manager 
84. 

[0121] In the active state of the response manager 86, the 
entire output buffer is written to the socket, one Unit Data 
Block (UDB) 74 at a time. An ABORT message is sent to the 
request manager 84 if an error occurs in the transmission of 
the output data to a client 40. Once the response manager 86 
is informed by the request manager 84 that the last request 
message has been received, the response manager 86 closes 
down the TCP/IP connection for the request in process. 

[0122] 3.4 Protocol for Performing a Network Manage- 
ment Transaction Between A Web-Enabled Network Man- 
agement agent and A Web Browser (the Hypertext Network 
Management Protocol) 

[0123] A web-enabled network management agent 30, 
which is capable of receiving a network management 
request from a client 40, in the form of a web browser, and 
of propagating the results of a network management func- 
tion performed in response to such a request in a format 
capable of display by the browser, has been described above. 
A description of the protocol by which request messages are 
propagated from the client 40 to the agent 30, and by which 
response messages are propagated from the agent 30 to the 
client 40, will now be described. 

[0124] The existing HTTP protocol is specifically directed 
towards performing a method (or operation) on a single 
object identified by a URI, URN or URL. The methods 
specified by the HTTP protocol are directed towards the 
retrieval of static documents, such as HTML documents, as 
well as the storing of documents under a specified URL. The 
method of operation on a URL object is specified by the 
client. However, the HTTP protocol is particularly unsuited 
to network management functions for a number of reasons. 
For example, the HTTP protocol does not facilitate the 
retrieval or manipulation of multiple URL objects. Accord- 
ingly, complex and clumsy Application Program Interfaces 
(APIs) and Common Gateway Interfaces (CGIs) must be 
written to allow for the management of objects on the server 
side. 

[0125] The Hypertext Network Management Protocol 
(HNMP) proposed by the present invention seeks to address 
the limitations of the HTTP protocol with respect to network 
management functions by introducing an embedded method 
token directly into a URL string. The method specified by 
the embedded method token is then applied to a URL object. 
Accordingly, the HNMP protocol provides a greater degree 
of functionality than the HTTP protocol, making the HNMP 
protocol particularly suitable for network management pur- 
poses. 

[0126] 3.4.1 Functional Software Layers 

[0127] Referring to FIG. 10A there is shown a diagram- 
matic representation of the software functional layers resi- 
dent on the network device 14 shown in FIG. IB. The 
functional layers comprise an operating system layer 160, a 
transport layer 162, a protocol layer 164 and an application 
layer 166. The transport layer 162 may include a TCP/IP 
protocol 168, which provides the transport layer for the 
HTTP protocol 170, and a UDP protocol 172 which provides 
the transport layer for the SNMP protocol 174. As described 



above, a proxy agent 176 translates messages formatted 
according to the HTTP protocol to a format specified by the 
SNMP protocol, and vice versa. An HTML server 178 is able 
to communicate with a client, in the form of a web browser, 
using the HTTP protocol 170, and a network management 
agent 180 is able to communicate with a network manage- 
ment application via the SNMP protocol 174. 

[0128] Referring now to FIG. 10B, there is shown a 
diagrammatic representation of the software functional lay- 
ers installed on a network device which is capable of 
communicating with a browser using the HNMP protocol, 
and having a web-capable agent according to the invention 
installed thereon. The functional layer structure shown in 
FIG. 10B differs from that shown in FIG. 10A in that the 
protocol layer need not include a proxy agent or the SNMP 
protocol. The application layer 166 comprises the web- 
capable network management agent 186, and a URL dictio- 
nary 188. The agent 186 is able to communicate with a web 
browser utilizing any of the protocols included in the 
protocol layer 164. 

[0129] 3.4.2 Response-Request Exchange 

[0130] Referring now to FIG. 11, there is shown a method 
by which request and response messages are exchanged 
between an HTML client, such as a web browser, and a 
web-capable network management agent, functioning as an 
HTML server. At step 202, the client and the agent enter into 
a protocol negotiation, and establish the HNMP protocol as 
the communication protocol. Contrary to the HTTP protocol 
wherein a connection between a client and a server is 
severed once a request or a response message has been 
transmitted, the agent 30 maintains a TCP/IP connection 
between the client and itself until the client severs the 
connection, or the agent itself severs the connection. 
Accordingly, numerous request and response exchanges can 
occur without the connection being severed. 

[0131] At step 204, the client propagates, and the agent 30 
receives, a request message requesting that the agent 30 
supply a URL Dictionary 60 to the client. As discussed 
above, the URL Dictionary 60 comprises a list of manage d 
o bjects supported by the agen t. At step 206, the agent 30 
propagates a response message to the client, the response 
mej^ageincorporatmg4he-URL^Dictipjiar y 60. Accor dingly, 
the^cjiejitJs_ableUo,ascertai^ 

which^managed objects are supported by the agentSD. The 
agent 30 furthermore includes an HTML document in the 
body of the response message. This HTML document is 
displayable by the client to present a user with a-menu of 
various network management options that canjbe exercised. 
More specifically, the HTML document contains the hyper- 
text links to managed objects supported by the agent 30. The 
HTML document may optionally present the network man- 
agement functions in a tabular form. 

[0132] At step 208. the client p ropagates a reque st tr> 
age nt 30. the request includin g an instruction to perfo rm a 
network managemen tiunclion. The request further identifies 
one or more managed objects, extracted from the URL 
Dictionary 60, on which the network management function 
is to be performed. In one embodiment, the network man- 
agement function is either a GET, SET or TRAP function. 
Each managed object identified within the request message 
is identified by an object identifier, which is extracted from 
an OBJECT IDENTIFIER field 66 of a respective entry 
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within the URL Dictionary 60. For example, the object 
identifier "1.3.6.2.1.1.1" would identify the "sysDescr" MIB 
object. At step 210, the agent 30 performs the function on the 
managed objects, according to the object identifier in the 
request message from the client. At step 220, the agent 30 
propagates an appropriate response message back to the 
client. 

[0133] It will be appreciated that once steps 202, 204 and 
206 have been completed, the client is able to transmit 
numerous request messages, either automatically or in 
response to a manual input from a user, to the agent 30, 
requesting various network management functions. Thus, 
for each occasion that steps 202-206 are performed, the 
method may involve numerous iterations of steps 208-212. 

[0134] The agent 30 may also generate an unsolicited 
"response" message for propagation to the client in the event 
of an alarm or alert condition, which requires a network 
administrator's immediate attention. Such alarm responses 
may also be generated in response to a trap installed on the 
agent 30. 

[0135] FIG. 12 shows a specific example of the method 
200, in which the request message propagated at step 208 
includes a GET instruction and identifies one or more MIB 
objects extracted from a URL Dictionary 60. In this case, at 
step 210, the network management agent will determine 
specific values (or instances) of the MIB objects, and these 
values, paired with the appropriate object identifiers, will be 
propagated back to the client from the agent at step 212. 

[0136] Certain network management functions may allow 
data values to be assigned to certain MIB objects. FIG. 13 
shows a further specific embodiment of the method 200, in 
which the network management function comprises a SET 
instruction, which is propagated within a request message, 
together with one or more MIB object identifiers and asso- 
ciated data values, from the client to the agent at step 208. 
At step 210, the agent 30 assigns the data values to the 
respective MIB objects, and at step 212 the agent transmits 
a response to the client, acknowledging success or failure of 
the set instruction. 

[0137] FIG. 14 shows yet another specific embodiment of 
the method 200. At step 210, a request message including a 
TRAP instruction, and listing one or more MIB objects 
extracted from the URL Dictionary 60, is propagated from 
the client to the agent 30. At step 210, the agent 30 creates 
traps on the listed MIB objects. Accordingly, any change in 
the value of the MIB objects identified in the request 
message will cause a response message to be transmitted to 
the client. At step 212, the agent 30 transmits a response 
message to the client, confirming the creation of the 
requested traps. 

[0138] FIGS. 15A-15C provide a representation of the 
exchange of request and response messages between an 
HNMP client and an agent 30, functioning as an HNMP 
server. 

[0139] The GET instructions discussed above are particu- 
larly useful in allowing a browser to display an instanta- 
neous measurement or value of a certain network manage- 
ment function parameter, identified by a MIB object. 
Furthermore, by periodically transmitting GET requests to 
an agent 30, a client in able to provide a network manager 
viewing a browser with a continual update of a monitored 



parameter or MIB object. For example, an object identifier 
may address a "GOOD FRAMES" managed object, which 
maintains a record of the number of uncorrupted message 
frames received at a specific network device which the agent 
is monitoring. By continually directing a GET instruction at 
such a "GOOD FRAMES" managed object, the client is able 
to provide a network manager with a continual indication of 
the number of uncorrupted frames being received at the 
network device. Similarly, by setting a trap on, for example, 
the "GOOD FRAMES" managed object, a user can be 
provided with a continual update regarding the number of 
uncorrupted frames received at the network device. 

[0140] As mentioned above, a response message from the 
agent 30 (in response to a request incorporating a GET 
instruction) incorporates at least one object identifier and a 
data value assigned to that object identifier. The data value 
may be incorporated in an HTML document for display as 
a numeric value. Alternatively, the data value may be 
utilized by a JAVA™ applet residing on the network device, 
which interacts with the agent 30, to provide a graphic 
display of a monitored network parameter. 

[0141] FIGS. 15A-15C provide a diagrammatic represen- 
tation of the exchange of requests and response messages for 
each of the specific embodiments of the method 200 shown 
in FIGS. 12-14. The term "varList" is shown to be incor- 
porated in a number of the response and request messages, 
and refers to a variable list incorporating at least one object 
identifier, which may or may not have a data value associ- 
ated therewith. 

[0142] 3.4.3 Request and Response Message Format 

[0143] FIG. 16 provides a diagrammatic representation of 
the structure of a request message 220, which is propagated 
from the client to the agent 30. The request message 220 
comprises three primary portions, namely a request line 222, 
a header 224 and an entity body 226. The request line 222 
includes an embedded method token 222.1. The request line 
222 is particularly significant in that the method token 222.1 
is embedded therein, and specifies an action (or method) to 
be applied to a managed object identified within the request 
message 220. Furthermore, the request line 222 may include 
multiple method tokens. For example, embedded method 
tokens could specify GET, SET or TRAP functions, as 
described above, to be performed on the managed objects 
listed within the request message. 

[0144] The header 224 contains further information fields, 
including a message identifier field 224.1 which lists the 
network management functions or methods known to the 
agent 30. In one embodiment, these would include the GET, 
SET and TRAP methods. This list of network management 
functions is established during the protocol negotiation 
phase between the client and the agent 30. 

[0145] The entity body 226 incorporates a variable list 
field 226.1 which may accommodate a list of object iden- 
tifiers and respective values associated with each of these 
object identifiers. A request message sent from a client to an 
agent 30 to request the URL Dictionary 60 will contain no 
values in the variable list. A request message incorporating 
a GET method token in the request fine 222 will merely 
contain object identifiers, which will have no values asso- 
ciated therewith. A request message incorporating a SET 
instruction, as illustrated in FIG. 15B, will include at least 
one object identifier and a value associated therewith. 



07/08/2002, EAST Version: 1.03.0002 



US 2002/0046268 Al 



9 



Apr. 18, 2002 



[0146] Referring now to FIG. 17, there is shown a dia- 
grammatic representation of a response message 230. The 
response message 230 includes a status line 232, a header 
234 and an entity body 236. As shown, the header 234 may 
include both a message identifier and an error identifier. The 
entity body 236 includes a variable list field 236.1, as 
detailed above. In a response message sent from an agent 30 
in response to a request message incorporating a GET 
method token, the variable list field 236.1 will incorporate at 
least one object identifier and an associated value. 

[0147] In conclusion, the protocol for performing a net- 
work management transaction and the web-capable network 
management agent of the present invention are particularly 
advantageous in that they provide a mechanism whereby 
network management can be performed over an internet or 
an intranet using a web browser. The protocol proposed by 
the present invention is advantageous in that it addresses the 
inadequacies of the HTTP protocol with respect facilitating 
network management by allowing the retrieval and manipu- 
lation of multiple managed objects utilizing a single request 
message. Furthermore, the protocol proposed by the present 
invention allows a continuous and dedicated TCP/IP con- 
nection to be established between a client and a network 
management agent 19, thus allowing a network manager, 
utilizing a browser, continually to monitor various aspects of 
a network device. As the HNMP protocol furthermore 
utilizes the TCP/IP transport protocol, it is more robust and 
reliable than the SNMP protocol, which uses the UDP 
transport layer protocol. 

[0148] The network management agent 30 of the present 
invention is furthermore advantageous in that it communi- 
cates with a client in a language understood by the client, 
(for example HTML) and accordingly obviates the need for 
a proxy agent- The network management agent 30 allows a 
client to directly and effectively access network manage- 
ment functions provided by the agent. 

[0149] Thus, a method of performing a network manage- 
ment transaction using a web-capable agent has been 
described. Although the present invention has been 
described with reference to specific exemplary embodi- 
ments, it will be evident that various modifications and 
changes may be made to these embodiments without depart- 
ing from the broader spirit and scope of the invention. 
Accordingly, the specification and drawings are to be 
regarded in an illustrative rather than a restrictive sense. 



What is claimed is: 

1. A method of performing a network management trans- 
action between a network device having a network manage- 
ment agent installed thereon and a remote device having a 
browser installed thereon, the method comprising the steps 
of: 

(a) performing a network management function relating to 
the network device; and 

(b) propagating data concerning the network management 
function from the agent to the remote device in a format 
capable of display by the browser. 

2. The method of claim 1 wherein step (b) comprises 
propagating a document from the agent to the remote device 
for display by the browser, the document incorporating the 
data concerning the network management function. 

3. The method of claim 2 wherein the document is an 
HTML document. 



4. The method of claim 1 wherein step (b) comprises 
propagating the data in a format for display by the browser 
under the direction of an application program resident of the 
remote device. 

5. The method of claim 1 wherein the network manage- 
ment function is performed in response to a network man- 
agement request issued from the browser. 

6. The method of claim 5 including the step of receiving 
a data packet at the agent, the data packet including a 
plurality of network management requests. 

7. The method of claim 5 wherein the network manage- 
ment function addresses a network management object, and 
wherein step (a) includes the step of associating an object 
identifier included within the network management request 
with the network management object. 

8. The method of claim 1 including the step of propagat- 
ing a list of network management functions supported by the 
agent from the agent to the remote device. 

9. The method of claim 1 including the step of propagat- 
ing a menu document from the agent to the remote device for 
display by the browser, the menu document providing an 
option to issue a network management request from the 
browser to the agent. 

10. The method of claim 1 wherein the menu document 
includes static information concerning the network device. 

11. The method of claim 1 wherein the network manage- 
ment function is the retrieval of network management infor- 
mation. 

12. The method of claim 1 wherein the network manage- 
ment function is the allocation of a value to a network 
management object. 

13. The method of claim 1 wherein the network manage- 
ment function is the setting of a trap on a network manage- 
ment object. 

14. The method of claim 1 including the step of estab- 
lishing a connection between the agent and the browser, and 
maintaining the connection for multiple network manage- 
ment transactions between the agent and the remote device. 

15. A computer-readable medium having stored thereon a 
plurality of instructions which, when executed by a proces- 
sor of a network device, cause the processor to perform the 
steps of: 

performing the network management function relating to 
the network device; and 

propagating data concerning the network management 
function from the network device to a remote device in 
a format capable of display by a browser resident on the 
remote device. 

16. The computer-readable medium of claim 15 having 
stored thereon instructions which cause the processor to 
perform the step of propagating a document from the agent 
to the remote device for display by the browser, the docu- 
ment incorporating the data concerning the network man- 
agement function. 

17. The computer-readable medium of claim 15 having 
stored thereon instructions which cause the processor to 
perform the step of propagating the data in a format for 
display by the browser under the direction of an application 
program resident of the remote device. 

18. The computer-readable medium of claim 15 having 
stored thereon instructions which cause the processor to 
perform the step of propagating a list of network manage- 
ment functions supported by the agent from the agent to the 
remote device. 
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19. The computer-readable medium of claim 15 having 
stored thereon instructions which cause the processor to 
perform the step of propagating a menu document from the 
network device to the remote device for display by the 
browser, the menu document providing an option to issue a 
network management request from the browser to the net- 
work device. 

20. The computer-readable medium of claim 15 having 
stored thereon instructions which cause the processor to 
perform the network management function of retrieving 
network management information. 

21. The computer-readable medium of claim 15 having 
stored thereon instructions which cause the processor to 
perform the network management function of allocating a 
value to a network management object. 

22. The computer-readable medium of claim 15 having 
stored thereon instructions which cause the processor to 



perform the network management function of setting a trap 
on a network management object. 

23. The computer-readable medium of claim 1 having 
stored thereon instructions which cause the processor to 
perform the step of establishing a connection between the 
network device and the remote device, and maintaining the 
connection for multiple network management transactions 
between the network device and the remote device. 

24. The computer-readable medium of claim 1 wherein 
the network management function addresses a network 
management object, the computer-readable medium having 
stored thereon instructions which cause the processor to 
perform the step of associating an object identifier included 
within a management request received at the network device 
with the network management object. 

* * * + * 
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